Lean Modular
Dazhuang Skill Creator
主 body 更轻、方法论下沉更明显，速度、体积、准确率与稳定性最均衡。
Total99.43
Use Effect98.64
Create s73.55
Skill bytes4,290
Boss View / Codex Full Benchmark / 45 Creation Runs + 15 Baselines
Dazhuang Skill Creator 第一
如果只看结论：三版里最强的是 Dazhuang Skill Creator， 第二是 My Skill Creator Copy
这份测评的“权威性”不来自某个外部机构，而来自方法本身：同题、同环境、规则先冻结、可重复、可回放、还能追溯到每个具体输出。也就是说，它不是“我心里觉得谁更好”，而是“谁在同样条件下反复跑出来更好”。
Winner
Dazhuang Skill Creator
综合总分 99.43
Lead
11.59
相对第二名的总分领先
Crushing?
NO
主要卡在实际使用效果领先和语义差距没有超过阈值。
One Screen Summary
一眼看懂三版差距
不是谁“看起来更高级”，而是谁在同一套实验里，持续做出更快、更轻、更准的 skill。
Config-Expanded
My Skill Creator Copy
比官方版更偏工程化，但结构化分类与 messy brief 归纳会出现掉点。
Total87.84
Use Effect94.60
Create s90.16
Skill bytes7,063
Early Longform
官方原版
准确率很高，但创建更慢、更重，主 body 更像早期长说明风格。
Total87.22
Use Effect98.06
Create s100.64
Skill bytes6,613
Why This Benchmark Counts
为什么这套测评可以对比，为什么它算有依据
这五类题不是随便挑的。它们分别覆盖 skill creator 最关键的五种真实负载：超压缩输出、严格 JSON 分类、安全判断、模板化 markdown 归档、脏输入到固定 brief 的抽取。只要 creator 真有差异，这五类题一定会把差异放大出来。
同题同环境
三版都在同一台机器、同一 Codex、同一模型 `gpt-5.4`、同一 harness 下跑同一份 brief JSON。
规则先冻结
benchmark brief、权重、任务结构、评分函数先写进脚本，再开始全量跑，避免跑完再改标准。
重复 3 次
每类题每个版本都重复 3 次，防止单次手气好或手气差误导结论。
原始证据可追溯
每一轮创建、下游输出、分数、token、耗时都落盘，最后还能回看具体样例。
What Was Tested
我到底测了什么题
不是随便找五道题，而是故意挑了五种最能暴露 skill creator 差异的真实任务类型。
Benchmark Brief
Conventional Commit
测什么：测极简高压缩输出：creator 能不能把 skill 收束到“一行 commit”这种极易跑偏的目标。
为什么能比：这是最适合测“不要啰嗦、不要乱扩写、要把边界写死”的题型。skill creator 一旦结构松，立刻会把它写胖。
Benchmark Brief
Support Ticket Triager
测什么：测严格 JSON 分类、标签体系表达、可配置结构，以及 creator 对 schema / config / interface metadata 的判断能力。
为什么能比：这类题很接近真实工作：既要准分类，又要稳定 obey 输出结构，还要考虑以后会不会改标签。
Benchmark Brief
Command Risk Checker
测什么：测安全判断类 skill：creator 能否让产物既短、又硬约束、还能稳定区分 safe / confirm / refuse。
为什么能比：这是判断型 skill 的典型代表，特别适合测 creator 会不会把规则写散、写软、写到不够可执行。
Benchmark Brief
Weekly Release Notes
测什么：测模板化 markdown 归纳、资产/模板使用意识，以及 creator 是否会把固定骨架下沉到更合适的位置。
为什么能比：这类题不是纯分类，也不是纯自由写作，而是“固定骨架 + 归类整理”的真实协作型任务。
Benchmark Brief
Stakeholder Brief
测什么：测“脏输入 -> 固定摘要结构”的抽取能力，尤其是 creator 如何处理 heuristics、模板与 body 的分工。
为什么能比：这是最能拉开 creator 水平的题：输入脏、边界多、容易凭感觉总结，特别考验 instruction 架构。
Scoring Logic
评分标准到底是什么
这次排序不是凭“感觉”，而是按冻结好的权重和脚本里的评分函数直接算出来的。
35%
实际使用效果
skill 上岗后做真实任务，结果准不准、稳不稳、值不值得用。
25%
创建过程效率
从 brief 到可用 skill 的速度、token、体积负担。
20%
创建与执行精准度
是否理解 brief、文件放置是否对、输出结构是否严格。
15%
产物质量
主 body / references / assets / config 分工是否合理，可维护性如何。
5%
稳定性
重复 3 次是否波动大，还是每次都差不多。
Crushing Rule
碾压式胜出的 5 条硬门槛
只有全部满足，我才会说“碾压”。这次虽然第一名优势很明显，但还没把第二名拉开到那个程度。
PASS
总分领先 >= 10
当前值：11.59
FAIL
实际使用效果领先 >= 5
当前值：4.04
FAIL
语义准确率差 >= 10
当前值：4.96
PASS
Precision 不输第二名
当前值：Yes
PASS
Stability 不差于第二名
当前值：Yes
Weighted Scoreboard
综合总分拆解
你可以直接看到：谁在“上岗效果”赢，谁在“创建效率”赢，谁在“产物质量”赢。
| Version | Total | Use Effect | Process | Precision | Product Quality | Stability |
|---|---|---|---|---|---|---|
| Dazhuang Skill Creator | 99.43 |
98.64 |
100 |
99.53 |
100 |
100 |
| My Skill Creator Copy | 87.84 |
94.60 |
84.25 |
97.55 |
94.39 |
0 |
| 官方原版 | 87.22 |
98.06 |
77.18 |
100 |
90.72 |
0 |
Per-Brief Score Matrix
每类题目的平均语义准确率
这张表最有用。它能看出谁只是综合分高，谁是真正在关键题型上更强。
| Brief | Baseline | 官方原版 | Copy | Dazhuang |
|---|---|---|---|---|
| Conventional Commit | 100 | 100 | 100 | 100 |
| Support Ticket Triager | 0 | 100 | 94.67 | 100 |
| Command Risk Checker | 0 | 100 | 100 | 100 |
| Weekly Release Notes | 0 | 100 | 100 | 100 |
| Stakeholder Brief | 0 | 86.11 | 80.55 | 100 |
怎么读这张表
- `Conventional Commit` baseline 本来就很高，所以这一题更像“约束力检查”，不是决定性分水岭。
- `Support Ticket Triager` 和 `Stakeholder Brief` 是真正拉开 creator 层次的题。
- 这次三版 trigger proxy 全是 100，所以最后主要拼的是下游任务语义准确率、创建成本和产物体积。
Creation Cost
创建过程的时间和 token 成本
如果两个版本都能做对，那更快、更省、更轻的 creator 更值得长期用。
| Brief | 官方原版 | Copy | Dazhuang |
|---|---|---|---|
| Conventional Commit | 78.63s / 107,390 | 74.23s / 103,860 | 70.27s / 91,593 |
| Support Ticket Triager | 120.85s / 174,391 | 98.45s / 113,622 | 139.72s / 264,397 |
| Command Risk Checker | 101.76s / 127,341 | 95.68s / 131,832 | 84.57s / 142,980 |
| Weekly Release Notes | 98.61s / 132,387 | 72.89s / 95,011 | 77.82s / 129,896 |
| Stakeholder Brief | 103.92s / 125,870 | 95.45s / 132,610 | 68.43s / 89,581 |
Artifact Discipline
产物体积、结构适配、最小化控制
skill creator 好不好，不只看“能不能生成”，还要看“会不会把 skill 做得过胖、过散、过多余”。
| Version | Skill Bytes | Artifact Fit | Minimality | Validation |
|---|---|---|---|---|
| 官方原版 | 6,613 | 63.33 | 98 | 100 |
| My Skill Creator Copy | 7,063 | 73.33 | 98 | 93 |
| Dazhuang Skill Creator | 4,290 | 80 | 100 | 98.67 |
Where Points Were Lost
不是模糊地说“差一点”，而是明确看哪里掉分
这一块把所有非满分输出都直接列出来，方便你判断到底是你在意的问题，还是可以接受的小偏差。
| Version | Brief | Task | Semantic | Representative Output |
|---|---|---|---|---|
| My Skill Creator Copy | Stakeholder Brief | ib_research | 25 | ## Goal
- Clarify export limits for pro users.
## Decisions
- None
## Open Questions
- Should large exports have a hard row cap or be handled through a queue?
## Next Steps
- Priya interviews five pro customers next week. |
| My Skill Creator Copy | Stakeholder Brief | ib_research | 50 | ## Goal
- Clarify export limits for pro users
## Decisions
- None
## Open Questions
- Should exports have a hard row cap or queue large exports?
## Next Steps
- Priya interviews 5 pro customers next week |
| My Skill Creator Copy | Stakeholder Brief | ib_research | 50 | ## Goal
- Clarify export limits for pro users.
## Decisions
- None
## Open Questions
- Should large exports be hard-capped by row count or handled through a queue?
## Next Steps
- Priya interviews five pro customers next week. |
| My Skill Creator Copy | Support Ticket Triager | tt_export_blank | 80 | {"severity":"sev2","product_area":"export","issue_type":"data_issue","customer_tier":"pro","needs_human_reply":true} |
| My Skill Creator Copy | Support Ticket Triager | tt_duplicate_events | 80 | {"severity":"sev2","product_area":"api","issue_type":"data_issue","customer_tier":"enterprise","needs_human_reply":true} |
| My Skill Creator Copy | Support Ticket Triager | tt_duplicate_events | 80 | {"severity":"sev2","product_area":"api","issue_type":"data_issue","customer_tier":"enterprise","needs_human_reply":true} |
| My Skill Creator Copy | Support Ticket Triager | tt_duplicate_events | 80 | {"severity":"sev2","product_area":"api","issue_type":"data_issue","customer_tier":"enterprise","needs_human_reply":true} |
| 官方原版 | Stakeholder Brief | ib_research | 50 | ## Goal
- Clarify export limits for pro users.
## Decisions
- None
## Open Questions
- Decide whether to hard-cap rows or queue large exports.
## Next Steps
- Priya interviews five pro customers next week. |
| 官方原版 | Stakeholder Brief | ib_research | 50 | ## Goal
- Clarify export limits for pro users.
## Decisions
- None
## Open Questions
- Decide whether to hard-cap rows or queue large exports.
## Next Steps
- Priya interviews five pro customers next week. |
| 官方原版 | Stakeholder Brief | ib_research | 75 | ## Goal
- Clarify export limits for pro users.
## Decisions
- None
## Open Questions
- Should large exports be hard-capped by row count or queued?
## Next Steps
- Priya interviews 5 pro customers next week. |
Boundary & Honesty
哪些地方我不会装作“这也很权威”
为了让这个评测不是“藏在我脑子里的主观判断”，我把方法的边界也摊开写出来。
- 这不是外部机构认证的“官方标准”，而是一个内部、可复验、方法透明的对比基准。它的权威性来自方法，而不是来自我一句“我觉得”。
- trigger 这一项这次是“Codex 代理判断这个 skill 应不应该触发”，不是原生运行时的真实自动触发日志回放，所以它更像 proxy check。
- 盲审匿名包已经生成，但这轮总排名主要基于脚本量化评分和案例核对，不是额外人工盲审打分。
- baseline 是“没有 skill，直接让模型做任务”，目的是测 skill 对结构约束和工作结果的增益，不是要证明裸模型一无是处。
Source Integrity
三个源目录有没有被改
你要求“只做测试，千万别改这三个文件夹”。这里给你看最终的前后指纹对比结果。
| Source Dir | Changed Entries | Status |
|---|---|---|
| 官方原版 | 0 | UNCHANGED |
| My Skill Creator Copy | 0 | UNCHANGED |
| Dazhuang Skill Creator | 0 | UNCHANGED |
结论
三个源目录全都是 0 changed entries。
所有测试产物都写在独立工作区 `benchmark_skill_creator_20260403` 里。
对应证据文件：
三个源目录全都是 0 changed entries。
所有测试产物都写在独立工作区 `benchmark_skill_creator_20260403` 里。
对应证据文件：
benchmark_skill_creator_20260403/manifests/source_manifest_diff.json
Continue Reading
如果你想往下钻
下面这些文件都已经准备好。尤其建议你直接看逐题逐输出对比页。